AOSD and Reflection: Benefits and Drawbacks to Software Evolution

Following last two years’ RAM-SE (Reflection, AOP and Meta-Data for Software Evolution) workshop at the ECOOP conference, the RAM-SE 2006 workshop was a successful and popular event. As its name implies, the workshop’s focus was on the application of reflective, aspect-oriented and data-mining techniques to the broad field of software evolution. Topics and discussions at the workshop included mechanisms for supporting software evolution, technological limits for software evolution and tools and middleware for software evolution. The workshop’s main goal was to bring together researchers working in the field of software evolution with a particular interest in reflection, aspect-oriented programming and meta-data. The workshop was organized as a full day meeting, partly devoted to presentation of submitted position papers and partly devoted to panel discussions about the presented topics and other interesting issues in the field. In this way, the workshop allowed participants to get acquainted with each other’s work, and stimulated collaboration. We hope this helped participants in improving their ideas and the quality of their future publications. The workshop’s proceedings, including all accepted position papers can be downloaded from the workshop’s web site and a post workshop proceeding, including an extension of the accepted paper is published byt the University of Magdeburg. In this report, we first provide a session-by-session overview of the presentations, and then present our opinions about future trends in software evolution. Workshop Description and Objectives Software evolution and adaptation is a research area, as also the name states, in continuous evolution, that offers stimulating challenges for both academic and industrial M. Südholt and C. Consel (Eds.): ECOOP 2006 , LNCS 4379, pp. 40–52, 2007. c © Springer-Verlag Berlin Heidelberg 2007 Ws AOSD and Reflection: Benefits and Drawbacks to Software Evolution 41 researchers. The evolution of software systems, to face unexpected situations or just for improving their features, relies on software engineering techniques and methodologies. Nowadays a similar approach is not applicable in all situations e.g., for evolving nonstopping systems or systems whose code is not available. Features of reflection such as transparency, separation of concerns, and extensibility seem to be perfect tools to aid the dynamic evolution of running systems. Aspectoriented programming (AOP in the next) can simplify code instrumentation whereas techniques that rely on meta-data can be used to inspect the system and to extract the necessary data for designing the heuristic that the reflective and aspect-oriented mechanism use for managing the evolution. We feel the necessity to investigate the benefits brought by the use of these techniques on the evolution of object-oriented software systems. In particular we would determine how these techniques can be integrated with more traditional approaches to evolve a system and the benefits we get from their use. The overall goal of this workshop was that of supporting circulation of ideas between these disciplines. Several interactions were expected to take place between reflection, aspect-oriented programming and meta-data for the software evolution, some of which we cannot even foresee. Both the application of reflective or aspect-oriented techniques and concepts to software evolution are likely to support improvement and deeper understanding of these areas. This workshop has represented a good meeting-point for people working in the software evolution area, and an occasion to present reflective, aspect-oriented, and meta-data based solutions to evolutionary problems, and new ideas straddling these areas, to provide a discussion forum, and to allow new collaboration projects to be established. The workshop was a full day meeting. One part of the workshop was devoted to presentation of papers, and another to panels and to the exchange of ideas among participants. Workshop Topics and Structure Every contribution that exploits reflective techniques, aspect-oriented programming and/or meta-data to evolve software systems were welcome. Specific topics of interest for the workshop have included, but were not limited to: – aspect-oriented middleware and environments for software evolution; – adaptive software components and evolution as component composition; – evolution planning and deployment through aspect-oriented techniques and reflective approaches; – aspect interference and composition for software evolution; – featureand subject-oriented adaptation; – unanticipated software evolution supported by AOSD or reflective techniques; – MOF, code annotations and other meta-data facilities for software evolution; – software evolution tangling concerns; – techniques for refactoring into AOSD and to get the separation of concerns. To ensure lively discussion at the workshop, the organizing committee has chosen the contributions on the basis of topic similarity that will permit the beginning of new 42 W. Cazzola et al. collaborations. To grant an easy dissemination of the proposed ideas and to favorite an ideas interchange among the participants, accepted contributions are freely downloadable from the workshop web page: http://homes.dico.unimi.it/RAM-SE06.html. The workshop was a full day meeting organized in four sessions. The first session was devoted to the Awais Rashid’s keynote speech on “Aspects and Evolution: The Case for Versioned Types and Meta-Aspect Protocols”. Each of the remaining sessions has been characterized by a dominant topic that perfectly describes the presented papers and the related discussions. The three dominant topics were: aspect-oriented modeling for software evolution, tools and middleware for software evolution, and technological limits to software evolution. During each session, half time has been devoted to papers presentation, and the rest of the time has been devoted to debate about the on-going works in the area, about relevance of the approaches in the software evolution area and the achieved benefits. The discussion related to each session has been brilliantly lead respectively by Theo D’Hondt, Mario Südholt and Hidehiko Masuhara. The workshop has been very lively, the debates very stimulating, and the high number of participants (see appendix A) testifies the growing interest in the application of reflective, aspectand meta-data oriented techniques to software evolution. Important References The following publications are important references for people interested in learning more about the topics of this workshop: – Pattie Maes. Computational Reflection. PhD thesis, Vrije Universiteit Brussel, Brussels, Belgium, 1987. – Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Videira Lopes, Jean-Marc Loingtier, and John Irwin. Aspect-Oriented Programming. In 11th European Conference on Object Oriented Programming (ECOOP’97), LNCS 1241, pages 220–242, Helsinki, Finland, June 1997. Springer-Verlag. – The proceedings of the International Conference on Aspect-Oriented Software Development (AOSD) from 2002 to 2006. See also http://aosd.net/archive/ index.php. – Several tracks related to aspect-oriented software development and evolution at the International Conference on Software Maintenance (ICSM) and the Working Conference on Reverse Engineering (WCRE), from 2002 onward. – The software evolution website at the Program Transformation wiki: http://www.program-transformation.org/twiki/bin/view/ Transform/SoftwareEvolution. 1 Workshop Overview: Session by Session In this section of the report we summarize the workshop. In particular, Shigeru Chiba, in the role of chairman of the invited talk session, will comment the Nierstrasz’s talk and the discussions raised from the talk, then a short summary of the the remaining sessions will follow. AOSD and Reflection: Benefits and Drawbacks to Software Evolution 43 Session on Aspects and Evolution Keynote Speech by Awais Rashid (Lancaster University, UK) Summary by Shigeru Chiba (Session Chair, Tokyo Institute of Technology) In the first morning session, we had a keynote talk by Dr. Awais Rashid: – Aspects and Evolution: The Case for Versioned Types and Meta-Aspect Protocol. Abstract. One of the often cited advantages of aspect-oriented programming (AOP) is improved evolvability. No doubt the modularisation support provided by aspects helps to localise changes thus supporting evolution. However, evolution often requires keeping track of changes in order to make them reversible. Furthermore, often such changes (and their reversal) needs to be done online, e.g., in case of business and mission critical systems that can’t be taken offline. In this talk, I will discuss whether current AOP mechanisms are suited to such evolution needs. I will highlight the need for first class support for versioned types as well as fullyfledged meta-aspect protocols and present some practical experiences of implementing these in the Vejal aspect language and its associated dynamic evolution framework. The talk will conclude with a roadmap of key research issues that need to be tackled to ensure that the full potential of aspects can be realised with regards to improving the evolvability of software systems. One of the often cited advantages of aspect-oriented programming (AOP) is improved evolvability. No doubt the modularisation support provided by aspects helps to localise changes thus supporting evolution. However, evolution often requires keeping track of changes in order to make them reversible. Furthermore, often such changes (and their reversal) needs to be done online, e.g., in case of business and mission critical systems that can’t be taken offline. In this talk, I will discuss whether current AOP mechanisms are suited to such evolution needs. I will highlight the need for first class support for versioned types as well as fullyfledged meta-aspect protocols and present some practical experiences of implementing these in the Vejal aspect language and its associated dynamic evolution framework. The talk will conclude with a roadmap of key research issues that need to be tackled to ensure that the full potential of aspects can be realised with regards to improving the evolvability of software systems. Dr. Rashid’s keynote was very interesting and led active discussion among participants. In particular, the first half of his talk was about a classic problem in AOP, which is the problem of obliviousness and quantification. Although it was first proposed by Filman and Friedman [10] that the primary properties of AOP are obliviousness and quantification, this issue has been actively discussed by many researchers. Dr. Rashid’s claim was that obliviousness and quantification are not mandatory properties of AOP but they are only desirable properties. According to his talk, the obliviousness property often makes modular reasoning difficult. Hence, open modules and XPIs have been proposed as technique for limiting the obliviousness property and enabling easier modular reasoning. This fact shows that this property is not necessary (therefore, it can be limited). The quantification property is also useful but most of aspects, for example, in the database transaction domain, are not heterogeneous aspects but homogeneous aspects. Homogeneous aspects do not need the complex functionality of the quantification property. His claim was appealing and led a number of comments, objections, and supports from the floor. Session on Aspect-Oriented Modeling for Software Evolution The second session was related to the use of the aspect-oriented modeling to support the software evolution, Theo D’Hondt (Vrije Universiteit Brussel, Belgium) was the chairman. Three papers have been presented: [7] Improving AOP Systems’ Evolvability by Decoupling Advices from Base Code. Alan Cyment, Nicolas Kicillof, Rubén Altman, and Fernando Asteasuain (University of Buenos Aires, Argentina). Alan Cyment gave the talk. 44 W. Cazzola et al. [16] Making Aspect Oriented System Evolution Safer. Miguel Ángel Pérez Toledano, Amparo Navasa Martinez, Juan M. Murillo Rodriguez, (University of Extremadura, Spain) and Carlos Canal (University of Málaga). Miguel Ángel Pérez Toledano gave the talk. [6] Design-Based Pointcuts Robustness Against Software Evolution. Walter Cazzola (DICo Università degli Studi di Milano, Italy), Sonia Pini, and Massimo Ancona (DISI Università degli Studi di Genova, Italy). Sonia Pini gave the talk. Session on Tools and Middleware for Software Evolution The papers in this session covered the topic of adaptive middleware to support software evolution. Mario Südholt (École de Mines de Nantes) has chaired the session. Three papers have been presented: [1] Evolution of an Adaptive Middleware Exploiting Architectural Reflection. Francesca Arcelli, and Claudia Raibulet (Università degli Studi di Milano-Bicocca, Italy). Claudia Raibulet gave the talk. [3] An Aspect-Oriented Adaptation Framework for Dynamic Component Evolution. Javier Cámara Moreno, Carlos Canal, Javier Cubo (University of Málaga, Spain), and Juan M. Murillo Rodriguez (University of Extremadura, Spain). Javier Cámara Moreno gave the talk. [12] An Aspect-Aware Outline Viewer. Michihiro Horie, and Shigeru Chiba (Tokyo Institute of Technology, Japan). Michihiro Horie has given the talk. Session on Technological Limits for Software Evolution The papers in this session explore the technological limits of the AOP and reflective techniques to support software evolution. Hidehiko Masuhara (University of Tokyo, Japan) has lead the session. Four papers have been presented: [18] Solving Aspectual Semantic Conflicts in Resource Aware Systems. Arturo Zambrano, Tomás Vera, and Silvia Gordillo (University of La Plata, Argentina). Arturo Zambrano has given the talk. [8] Statement Annotations for Fine-Grained Advising. Mark Eaddy, and Alfred Aho (Columbia University, USA). Mark Eaddy gave the talk. AOSD and Reflection: Benefits and Drawbacks to Software Evolution 45 [9] Dynamic Refactorings: Improving the Program Structure at Run-time. Peter Ebraert and Theo D’Hondt (Vrije Universiteit Brussel, Belgium). Peter Ebraert gave the talk. [13] Implementing Bounded Aspect Quantification in AspectJ. Christian Kästner, Sven Apel, and Gunter Saake (Otto-von-Guericke-Universität Magdeburg, Germany). Christian Kästner gave the talk. 2 Software Evolution Trends: The Organizers’ Opinion The authors, with this report, would like to go beyond the mere presentation of statistical and generic information related to the workshop and to its course. They try to speculate about the current state of art of the research in the field and to evaluate the role of reflection, AOSD and meta-data in the software evolution. Can or Cannot the AOP Support the Software Evolution? Comment by Walter Cazzola (Università di Milano, Italy) In [2], software evolution is defined as a kind of software maintenance that takes place only when the initial development was successful. The goal consists of adapting the application to the ever changing user requirements and operating environment. Software systems are often asked for promptly evolving to face critical situations such as to repair security bugs, to avoid the failure of critical devices and to patch the logic of a critical system. It is fairly evident the necessity of improving the software adaptability and its promptness without impacting on the activity of the system itself. This statement brings forth to the need for a system to manage itself to some extent, to dynamically inspect component interfaces, to augment its application-specific functionality with additional properties, and so on. Independently of the mechanism adopted for planning the evolution, it requires a mechanism that permits of concreting the evolution on the running system. In particular this mechanism should be able of i) extruding the code interested by the evolution from the whole system code, ii) carrying out the patches required by the planned evolution on the located code. Often, both these steps must occur without compromising the system stability and the services availability (that is, without stopping the system providing them). AOP [14] provides some mechanisms (join points, pointcut and aspect weaving) that allow of modifying the behavior and the structure of an application. The AOP technology better addresses functionality that crosscut the whole implementation of the application. Evolution is a typical functionality that crosscut the code of many objects in the system. Moreover, the AOP technology seems suitable to deal with the detection of the code to evolve and with the instrumentation of such a code. From AOP characteristics, it is fairly evident that AOP has the potential for providing the necessary tools for instrumenting the code of a software system, especially when 46 W. Cazzola et al. aspects can be plugged and unplugged at run-time. Pointcuts should be used to pick out a region of the code involved by the evolution, whereas the advices should be used to define how the selected region of code should evolve. Weaving such an aspect on the running system should either inject new code or manipulate the existing code, allowing the dynamic evolution of the system. Unfortunately, to define pointcuts that point out the code interested by the evolution is a hard task because such modifications can be scattered and spread all around the code and not confined to a well-defined area that can be taken back to a method call. Moreover the changes could entail only part of a statement, e.g., the exit condition of a loop or an expression, and not the entire statement. The AOP technology could be the right approach to deal with the evolution concern but some scenarios are difficult to administrate with the current aspect-oriented frameworks. The main issues that obstacle the use of the AOP approaches are: the granularity of the requested manipulation and the locality of the code to manipulate. The necessary granularity for the pointcut is too fine, traditional join point models refer to method invocation in several way whereas we want to be able to manipulate a single statements or a group of statements in somehow related. This means that we can manipulate the method execution at its beginning and at its ending but we cannot alter its computational flow requiring the execution of another statement between two statements of its body. These problems are due to the poor expressiveness of the pointcut definition languages and of the related join point models provided by most of the actual AOP frameworks. Nowadays AOP languages provide very basic pointcut definition languages that heavily rely on the structure and syntax of the software application neglecting its semantics. The developer has to identify and to specify in the correct way the pointcut by using, what we call the linguistic pattern matching mechanism; it permits of locating where an advice should be applied by describing the join points as a mix of references to linguistic constructs (e.g., method calls) and of generic references to their position, e.g., before or after it occurs. Therefore, it is difficult to define generic, reusable and comprehensible pointcuts that are not tailored on a specific application. Moreover, current join point model is too abstract. Join points are associated to a method call whereas a finer model should be adopted to permit of altering each single statement. Therefore, to benefit from the AOP technology, this one and the underlying join point models, have to support a finer granularity of the join point model with a pointcut declaration language that abstracts from the syntax and deals with the semantics/behavior of the application. A few attempts in this direction are under development [5, 11, 15]. Unanticipated Software Evolution: Does It Exist? Comment by Shigeru Chiba (Tokyo Institute of Technology, Japan) An interesting issue on software evolution is what kind of evolution we must support. For example, if we use AOP or reflection, we can extend our applications so that they can fit new requirements. However, if we anticipate future changes of requirements when we design the applications, we can prepare against those future changes. We will define extra interfaces for better modularity. We may apply some design patterns such as the visitor pattern. If we can perfectly anticipate future changes, we will not need AOSD and Reflection: Benefits and Drawbacks to Software Evolution 47 AOP or reflection. We will be able to prepare within confines of existing technologies such as object-oriented programming. Some readers might say the value of AOP and reflection is that they provide better syntax. Although preparation by existing technologies is often complicated, preparation by AOP or reflection is much simpler or unnecessary. However, I think that the real value of AOP and reflection is that they can be used for implementing unanticipated evolution. If we use AOP or reflection, we do not have to prepare against future changes at all when we design and implement a first version of our applications. On the other hand, existing technologies such as object oriented programming do not address unanticipated evolution. To adapt applications to new requirements, those technologies force developers to edit and modify source code of the applications. I think that the study in this research field should consider differences between anticipated evolution and unanticipated one. AOP vs. Reflection for Evolution Comment by Gunter Saake (University of Magdeburg, Germany) Evolution of software artifacts means continuous adaptation to a changing environment and changing requirements. However, this process can be performed on different abstraction levels and in different kinds of environments. Important dimensions for adaptation are the following: – Anticipated evolution can be foreseen at software production time. Typical techniques can be built-in parametrization and reconfiguration methods, e.g., based on components or design patterns. Unanticipated adaptation means the reaction on unforeseen changes, which is of course much harder. – The adaption process can be performed manually as part of the maintenance process. Automatic adaptation is possible in some situations but requires the detection of environmental changes and planning and validation of adaption steps by the software system itself. – Adaptation can take place on different abstraction levels, from the model level (for example UML) down to the code level. These dimensions are not independent and usually they overlap. For example, planning of an adaptation requires in most case a semantic-rich representation of the system and it is hard to plan on the syntactic code-level. How do AOSD and reflection fit to this general picture? Figure 1 shows the current situation for AOP and reflection techniques. AOP techniques can directly manipulate (syntactic) code. However, since common AOP techniques are based on the syntactic structure of the program it is hard to use them for semantic based tasks which are used for a fully automatic adaption. AOP is general enough to allow manual adaptation to unforeseen changes. Reflection and meta-programming on the other hand is based on an internal model of the software. Current technology can use reflection for automatic reconfiguration at runtime, which can be used for reaction on anticipated changes. Unanticipated changes are hard to cope with basic reflection techniques, because that would require besides the 48 W. Cazzola et al.